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Response to Amendment 

Applicant's arguments filed on February 15, 2008 have been 
considered and the finality of the previous office action has 
been withdrawn. New art rejection has been provided. 

Claims 1-17 and 19-26 are presented for examination. 



Claim Rejections - 35 USC §103 

The following is a guotation of 35 U.S.C. 103(a) which 
forms the basis for all obviousness rejections set forth in this 
Office action: 

(a) A patent may not be obtained though the invention is not identically 
disclosed or described as set forth in section 102 of this title, if the 
differences between the subject matter sought to be patented and the prior 
art are such that the subject matter as a whole would have been obvious at 
the time the invention was made to a person having ordinary skill in the 
art to which said subject matter pertains. Patentability shall not be 
negatived by the manner in which the invention was made. 

Claims 1,3,4, 7-10, 13, 14-15, 19,25, and 26 are rejected 

under 35 U.S.C. 103(a) as being unpatentable over Adelman et al . 

(US 6078957), hereinafter "Adelman" in view of Fleming US PUB. 



(20020152446) . 



Application/Control Number: 1 0/667,88 1 Page 3 

Art Unit: 2153 

As per claims 1 and 3, Adelman teaches a method comprising: 

receiving a keepalive message from a client (col. 8, lines 

14-16 and col. 9, lines 3-5); 

determining a measure of network load (packet loss is a 

measure of network load that is determined by the master, "... 

master calculates and stores a packet loss average value using 

the sequence number of the client keepalive message and the 

calculated adaptive keepalive interval." column 8, lines 20- 

23.) ; 

selecting a keepalive period (based on packet loss, an 
adaptive keep alive period is calculated, " ... the master 
calculates and stores a packet loss average value using the 
sequence number of the client keepalive message and the 
calculated adaptive [i.e. changes the ] keepalive interval", 
column 8, lines 20-23); 

reporting the selected keepalive period to the client 
station in a response to the received keepalive message (col. 
13, lines 42 to col. 14, lines 13) (selected keep alive period 
is reported to client, "As indicated above, the master 
periodically [presence server] sends out a master keepalive 
message containing the cluster member list, the adaptive 
keepalive interval ..." column 8, lines 31-33); and the 
client station responsively sending a keepalive message to a 
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presence server at a time determined based on the selected 
keepalive period (client sends keep alive messages with updated 
adaptive keepalive interval, "The non-master cluster members 
(clients) must also send keepalive message and ..." Column 9, 
lines 2-3 in conjunction with, "... when a client gets a master 
keepalive message 890 it updates its adaptive keepalive interval 
891 Column 9, lines 4-6). 

although Adelman shows substantial features of the claimed 
invention including selecting a keepalive period on measure of 
packet loss, he does not explicitly show where the keepalive 
period is based on network load. 

Nonetheless, this feature is well known in the art and would 
have been an obvious modification of the system disclosed by 
Adelman, as evidenced by Fleming. 

In analogous art, Fleming disclose adjusting heartbeat timeouts 
(keepalive period) based on observed conditions such network 
congestions (abstract and paragraph 0024) . Giving the teaching 
of Fleming, a person of ordinary skill in the art would have 
readily recognized the desirability and the advantage of 
modifying Adelman by employing the adaptive heartbeat system of 
Fleming in order to adaptively adjust heartbeat timeouts 
(keepalive) based on to observed network conditions. In this way 
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proper corrective action can be taken to minimize potential 
network failures. 

Adelman further teaches the presence server (cluster master, 
which is also cluster member, "... each of the cluster members 
is a computer system...", column 5, line 22; acting as master) 
querying a controller (has controller, "... and two Intel 
Ethernet controllers," column 5, line 24) that has access to 
network load information (FIG. 1 in conjunction with FIG. 4, 
FIG. 1 Item 110 is the cluster one ether net connected to other 
network units. To get the sequence number master must have 
queried and obtained the packet from the Ethernet controller.). 

For Claim 4: A presence server (master of the cluster) in a 
communication network (see FIG. 1, item 110, in conjunction with 
column 5, line 16-17, "...will be described as a cluster whose 
applications may be VPN tunnel...", which indicates that FIG. 1, 
Item 110 is a cluster) , comprising: 

a first module (see FIG. 8B, item 830, a module) arranged 
to receive keepalive messages from at least one client station 

(master got client keepalive) ; a second module (a second module, 
see FIG. 8B, item 835) arranged to select a keepalive period 

(FIG. 8B, Item 835, "CALCULATE AND STORE PACKET LOSS AVERAGE 
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(USING SEQUENCE NUMBER OF KEEP ALIVE AND ADAPTIVE KEEPALIVE 
INTERVAL)", Packet average loss is the measure of network load, 
and adaptive keepalive interval is keepalive period based on 
network load) ; a third module (FIG. 8C, item 851) arranged to 
report the selected keepalive period to the at least one client 
station (FIG. 8C, item 851, "BROADCAST MASTER KEEPALIVE 
CONTAINING CLUSTER MEMBER LIST AND ADAPTIVE KEEPALIVE 
INTERVAL") . 

As to the keepalive period being based on network load see the 
rejection on claim 1 and 3 above. 

For claim 7: The presence server of claim 4 (see supra for claim 
4 discussion) , wherein the presence server is coupled to a 
controller (a master which is also cluster member has two 
Ethernet controllers, "each of the cluster members is a computer 
system having an Intel motherboard, two Intel Pentium 
processors, a 64 megabyte memory and two Intel Ethernet 
controllers,..."), the controller keeping track of network load 
information (the controller receives the packets, therefore 
controller keeps track of packet sequence numbers, which in turn 
determine network packet loss-network load, "... when the master 
gets a 'client keepalive message 1 (that is one from a non-master 
cluster member) 830 . . . master calculates and stores a packet 
loss average value using sequence number of the client keepalive 
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message and the calculated adaptive keepalive interval.", Column 
8, lines 15-23) . 

For claim 8: The presence server of claim 4 (see supra for claim 
4 discussion) , wherein the presence server is embedded with a 
controller (a master which is also cluster member has two 
Ethernet controllers that are present on the mother board or 
attached to mother board, i.e. they are embedded, "each of the 
cluster members is a computer system having an Intel 
motherboard, two Intel Pentium processors, a 64 megabyte memory 
and two Intel Ethernet controllers.... ") that keeps track of 
network load information (the controller receives the packets 
with packet sequence number, therefore controller keeps track of 
packet sequence numbers, which in turn determine network packet 
loss, which is a measure of network load, "... when the master 
gets a 'client keepalive message' (that is one from a non-master 
cluster member) 830 . . . master calculates and stores a packet 
loss average value using sequence number of the client keepalive 
message and the calculated adaptive keepalive interval.", column 
8, lines 15-23) . 

For claim 9: Adelman teaches a system comprising: 

at least one client station (FIG. 4, Items 405-409 as non- 
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master cluster members) ; a presence server (Master acting as 
presence server and for description of master formation please 
refer to FIG. 6 - 8A, in conjunction with reference to column 6, 
line 40 - column 8, line 13); the presence server receiving a 
keepalive message from the at least one client station (col. 8, 
lines 14-16 and col. 9, lines 3-5); 

the presence server determining a keepalive period 

(keepalive period is determined by master based on packet loss, 
which is a measure of network load, "... when the master gets a 

'client keepalive message' (that is one from a non- master 
cluster member) 830 . . . master calculates and stores a packet 
loss average value using sequence number of the client keepalive 
message and the calculated adaptive keepalive interval.", column 
8, lines 15-23) based on network load (packet loss rate is a 
measure of network load) and sending an indication of the 
keepalive period to the at least one client station in a 
response to the keepalive message (col. 13, lines 42 to col. 14, 
lines 13) (FIG. 8C, item 851, "BROADCAST MASTER KEEPALIVE 
CONTAINING CLUSTER MEMBER LIST AND ADAPTIVE KEEPALIVE 
INTERVAL") ; 

the at least one client station sending keepalive signals 
according the keepalive period (See FIG. 8H, Item 912, "SEND 
CLIENT KEEP ALIVE TO MASTER CONTAINING MONOTONICALLY INCREASING 
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SEQUENCE # (FOR MEASURING NETWORK PACKET LOSS" in conjunction 
with column 9, lines 13-17, "Each client also has a periodic 
timer which is adaptive to the network packet loss value send by 
the master which requires the client to send a client keepalive 
message (containing a monotonically increasing numeric value) to 
the master periodically"). 

As to the keepalive period being based on network load see the 
rejection on claim 1 and 3 above. 

For claim 10: The system of claim 9 (see supra for claim 9 
discussion) , further comprising a controller that has access to 
network load information (FIG. 1 in conjunction with FIG. 4, 
FIG. 1 Item 110 is the cluster one ether net connected to other 
network units. To get the sequence number master must have 
queried and obtained the packet from the Ethernet controller.). 

For claim 13: The communication network of claim 9 is a packet- 
switched network (see FIG. 1, Item 110 the cluster connecting to 
internet 107 through communication link 109, It is well known 
that internet is a packet-switched network) . 

For claims 14 and 15: A method comprising: sending a first 
keepalive message from a client station to a presence server 
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(FIG. 8B, Item 830, "MASTER [master is presence server] GOT 
CLIENT KEEPALIVE " ) ; selecting a keepalive period based on a 
measure of network load (FIG. 8B, item 835, "CALCULATE AND STORE 
PACKET LOSS AVERAGE (USING SEQUENCE NUMBER OF KEEPALIVE AND 
ADAPTIVE KEEPALIVE INTERVAL", the packet loss average is network 
load and keepalive period is changed based on this load)"; 
reporting the selected keepalive period to the client station" 

(FIG. 8C, "BRAODCAST MASTER KEEPALIVE CONTAINIGN CLUSTER MEMBER 
LIST AND ADAPTIVE KEEPALIVE INTERVAL"); using the selected 
keepalive period to determine when the client station should 
send a next keepalive message to the presence server (See FIG. 
8H, Item 912, "SEND CLIENT KEEP ALIVE TO MASTER CONTAINING 
MONOTONICALLY INCREASING SEQUENCE # (FOR MEASURING NETWORK 
PACKET LOSS" in conjunction with column 9, lines 13-17, "Each 
client also has a periodic timer which is adaptive to the 
network packet loss value sent by the master ..."); sending the 
next keepalive message from the client station to the presence 
server (client, i.e. non-master sends the keep alive message to 
master, i.e. presence server, "... which requires the client to 
send a client keepalive message (containing a monotonically 
increasing numeric value) to the master periodically (see FIG. 
8H) [item 912].", column 9, lines 14-17). 
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As to the keepalive period being based on network load see the 
rejection on claim 1 and 3 above. 

For claim 19: Adelman teaches a client station (Cluster member 
as described in column 5, lines 22) in a communication network 
(see FIG. 1 Item 107), the client station comprising: a receiver 
(column 5, line 24, "... two Ethernet controllers", which 
implies a ether net phy with a receiver) ; a transmitter (column 
5, line 24, "... two Ethernet controllers", which implies a 
ether net phy with a transmitter) ; a timer (column 9, lines 13- 
16, "Each client also has a periodic timer which is adaptive to 
the network packet loss value sent by the master which requires 
the client to send a client keepalive message ..."); at least 
one processor (column 5, line 22, "... two Intel Pentium 
processors") ; data storage holding program instructions (FIG. 2, 
Item 217, CD-ROM medium in conjunction with column 4, line 42, 
"... a CD-ROM drive unit 217. The CD-ROM drive unit 217 can read 
a CD-ROM medium 219 which typically contains program 221 ...",); 
the program instructions being executable by the at least one 
processor to send a keepalive message through the transmitter, 
and to receive through the receiver a response to the keepalive 
message, the response containing information defining a 
keepalive period, the keepalive period being selected based on 
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network load (column 9, lines 13-16 and col. 13, lines 42 to 
col. 14, lines 13); and 

the program instructions being executable by the at least 
one processor, in response to receiving information defining a 
keepalive period wherein the keepalive period is selected based 
on network load (column 9, lines 13-16, "Each client also has a 
periodic timer which is adaptive to the network packet loss 
value [network packet loss value is a measure of network load) 
sent by the master which requires the client to send a client 
keepalive message ..."), to: (i) set the timer according to the 
keepalive period (column 9, lines 13-16, "Each client also has a 
periodic timer which is adaptive to the network packet loss 
value [network packet loss value is a measure of network load) 
sent by the master which requires the client to send a client 
keepalive message ..."); (ii) send a new keepalive message 
through the transmitter when the timer expires (column 9, lines 
13-16, "Each client also has a periodic timer which is adaptive 
to the network packet loss value [network packet loss value is a 
measure of network load) sent by the master which requires the 
client to send a client keepalive message ..."). 
As to the keepalive period being based on network load see the 
rejection on claim 1 and 3 above. 
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For claim 25: A presence server in a communication network 
comprising: a database, the database maintaining a list client 
stations that are connected to the network (column 8, lines 31- 
33, "As indicated above the master periodically sends out a 
master keepalive message containing the cluster member list 
since cluster member list is being sent, they must be 
stored in a database) ; a timer (column 9, lines 13-16, "Each 
client also has a periodic timer which is adaptive to the 
network packet loss value sent by the master which requires the 
client to send a client keepalive message ..."); wherein the 
presence server (master is the presence server) is programmed 
to: receive keep alive messages from at least one client station 
(See FIG. 8B, item 830, "MASTER GOT CLIENT KEEPALIVE"), select 
a keepalive period for the at least one client station based on 
a measure of network load (FIG. 8B, Item 835, "CALCULATE AND 
STORE PACKET LOSS AVERAGE (USING SEQUENCE NUMBER OF KEEPALIVE 
AND ADAPTIVE KEEPALIVE INTERVAL", where packet loss average is 
measure of network load based on which keepalive interval is 
determined.), report the selected keepalive period to the at 
least one client station in a response to the received keepalive 
message (col. 13, lines 42 to col. 14, lines 13) (FIG. 8C, item 
851, "BORADCAST MASTER KEEPALIVE CONTAINING CLUSTER MEMBER LIST 
AND ADAPTIVE KEEPALIVE INTERVAL"), and drop the at least one 
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client station from the database (FIG. 8E, ITEM 871, "DELETE 
CLIENT FROM CLUSTER DATA STRUCTURE") if the presence server does 
not receive new keepalive message within the selected keepalive 
period from the at least one client station (FIG. 8E, ITEMS 870, 
WATCHDOG TIMER FOR A CLIENT EXPIRES", which means presence 
server did not receive a keepalive message from the client.). 
As to the keepalive period being based on network load see the 
rejection on claim 1 and 3 above. 



For claim 26: A method comprising: sending a first keepalive 
message from a client station to a presence server (See FIG. 8B, 
item 830, "MASTER GOT CLIENT KEEPALIVE", which means client must 
have sent a keepalive message) ; selecting a keepalive period 
based on a measure of network load (FIG. 8B, Item 835, 
"CALCULATE AND STORE PACKET LOSS AVERAGE (USING SEQUENCE NUMBER 
OF KEEPALIVE AND ADAPTIVE KEEPALIVE INTERVAL", where packet loss 
average is measure of network load based on which keepalive 
interval is determined.); reporting the selected keepalive 
period to the client station in a response to the first 
keepalive message (col. 13, lines 42 to col. 14, lines 13) 
(FIG. 8C, item 851, "BORADCAST MASTER KEEPALIVE CONTAINING 
CLUSTER MEMBER LIST AND ADAPTIVE KEEPALIVE INTERVAL"); using the 
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selected keepalive period to determine when the client station 
should send a next keepalive message to the presence server 

(FIG. 8B, item 837, ".RESET WATCHDOG FOR THIS CLIENT", when this 
timer expires, i.e. with in adaptive keepalive interval if 
client does not send a keepalive message, client will be 
removed) ; updating a database of the presence server based on 
whether the client station has sent a next keep keepalive 
message to the presence within the selected keepalive period 

(FIG. 8E, item 870, WATCHDOG TIMER FOR CLINET EXPIRES", if 
keepalive message is received by master it watchdog timer would 
have been reset, See FIG. 8B, item 837 in conjunction with item 
830) . 

As to the keepalive period being based on network load see the 
rejection on claim 1 and 3 above. 



Claim Rejections - 35 USC §103 



The following is a quotation of 35 U.S.C. 103(a) which forms 
the basis for all obviousness rejections set forth in this 
Office action: 



(a) A patent may not be obtained though the invention is not identically 
disclosed or described as set forth in section 102 of this title, if the 
differences between the subject matter sought to be patented and the prior 
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art are such that the subject matter as a whole would have been obvious at 

the time the invention was made to a person having ordinary skill in the 

art to which said subject matter pertains. Patentability shall not be 

negatived by the manner in which the invention was made. 

5. Claims 2, 6, 12, 17, 20, 22 and 24 are rejected under 35 
U.S.C. 103(a) as being unpatentable over Adelman et al . in view 
of Harsch (US 6212175 Bl) . 

For claims 2, 6, and 12 Adelman et al . teaches everything except 
client being wireless mobile workstation, or presence server 
present in wireless communication network. The general concept 
of client being wireless workstation or presence server being 
present in wireless communication network is well known in the 
art as shown in Figure 1 use of MOBILE UNIT as client or 
presence server being present in a wireless network (Harsch: see 
the Figure 1, items 66, 66a, 66b, etc., which are mobile units 
which are present in a wireless communication network (see item 
67 indicating being wireless antenna) and presence server being 
Item 60, Host computer) . It would have been obvious to one in 
skilled in the art at the time of the invention to modify 
Adelman et al . to have a wireless mobile workstation and 
presence server in a wireless communication network in order to 
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sustain TCP connection as taught in Harsch (see title, "METHOD 
TO SUSTAIN TCP CONNECTION") . 

For claim 17, Adelman et al teaches all the limitations of claim 
17 except serving one or more wireless mobile subscribers in a 
wireless communication system. The general concept of serving 
one or more wireless mobile subscribers in a wireless 
communication system is well known in the art as illustrated by 
Harsch (FIG. 1, items 66, 66a, and 66b, several mobile units 
serving various subscribers in a wireless communication system) . 
It would have been obvious to one in skilled in the art at the 
time of the invention to modify Adelman et al to serving one or 
more wireless mobile subscribers in a wireless communication 
system in order to serve various mobile stations in a wireless 
communication system as taught in Harsch (see FIG. 1, serving 
various mobile units items 66, 66a, and 66b in a wireless 
communication network as shown in FIG. 1) . 

For claim 20: A system for dynamically determining keepalive 
periods in a wireless communication network, comprising: at 
least one base station (this claim limitation is not taught) ; at 
least one client station (FIG. 4, Items 405-409 as non-master 
cluster members) ; a presence server (FIG. 4, Item 403 as master, 
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acting as presence server) ; A packet switched network (see FIG. 
4, Items 411 and 107, INTERNET is known to be packet switched 
network) ; The presence server (master, which will be one of 
items 403-409) being capable of communicating with at least one 
client station (All items 403-409 which is not master are 
clients) through the packet-switched network (FIG. 8B, item 830, 
"MASTER GOT CLIENT KEEPALIVE " , since keepalive is a packet, it 
is implicit that there must be packet-switched network) ; the 
presence server determining a keepalive period (keepalive period 
is determined by master based on packet loss, which is a measure 
of network load, "... when the master gets a 'client keepalive 
message' (that is one from a non- master cluster member) 830 ... 
master calculates and stores a packet loss average value using 
sequence number of the client keepalive message and the 
calculated adaptive keepalive interval.", column 8, lines 15-23) 
at least one mobile subscriber (this claim limitation is not 
taught by Adelman et al) based on network load (packet loss rate 
is a measure of network load) and the presence server reporting 
the selected keepalive period (FIG. 8C, item 851, "BROADCAST 
MASTER KEEPALIVE CONTAINING CLUSTER MEMBER LIST AND ADAPTIVE 
KEEPALIVE INTERVAL") to the at least one mobile subscriber (this 
limitation is not taught by Adelman et al) through the packet- 
switched network (see FIG. 4, Items 411 and 107, INTERNET is 
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known to be packet switched network) ; Adelman et al teaches all 
the claim limitations as discussed above except for coupling a 
mobile client (s) through a base station to a packet switched 
network server. The general concept of coupling mobile user 
through a base station to a packet switched network server is 
well known in the art as illustrated by Harsch (see FIG. 1, 
items 66, 66a, and 66b mobile stations, coupled to server (host 
computer) through bases station 54a, wired line 52 (see page 4, 
Para 0037, lines 4-6, "The network backbone 52 may be a 
hardwired data communication path made of twisted pair cable, 
shielded coaxial cable or fiber optic cable, . ..") to item 60, 
host computer) . It would have been obvious to one in skilled in 
the art at the time of the invention to modify Adelman et al to 
couple mobile client (s) through a base station in order to make 
mobile units to be part of a cluster as taught in Harsch and 
Adelman (Harsch: see FIG. 1, mobile units 66, 66a, and 66b 
connected to ° host computer, 60; Adelman: FIG. 8F, showing 
joining of client into a cluster.) . For claim 22: The system of 
claim 20 (see supra for claim 20 discussion) , wherein the 
presence server (cluster master, which is also cluster member, 
"... each of the cluster members is a computer system 
column 5, line 22; acting as master) determines measures of 
network load (determined by using the sequence number of 



Application/Control Number: 1 0/667,88 1 Page 20 

Art Unit: 2153 

keepalive and keepalive interval, Adelman: see FIG. 8C, item 
835; sequence number is the only variable to determine the 
network load.) by querying a controller that has access a 
measure of network load (FIG. 1 in conjunction with FIG. 4, FIG. 
1 Item 110 is the cluster one ether net connected to other 
network units. To get the sequence number master must have 
queried and obtained the packet from the Ethernet controller.). 
As to the keepalive period being based on network load see the 
rejection on claim 1 and 3 above. 



For claim 24: The system of claim 20 (see supra for claim 20 
discussion) , wherein the at least one mobile subscriber (after 
Harsch modification of alderman as discussed supra, mobile 
station is non-master client) upon receiving the selected 
keepalive period (Adelman: FIG. 8G, Item 890, "CLIENT GOT MASTER 
KEEPALIVE"), sends the next keepalive message at a time 
determined by the selected keepalive period Item 891, "UPDATE 
ADAPTIVE KEEPALIVE INTERVAL (CALCULATED BY MASTER)", updating 
the keepalive interval has the effect of sending the next 
keepalive message according to the updated keepalive interval.). 
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6. Claims 5 and 11 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Adelman et al and Fleming in view of Rashid et 
al (US 2004/0230661) . 

For Claim 5 and 11 Adelman et al and Fleming teach all the claim 
limitations except for polling (polling for claim 5) and pushing 
(for claim 11) the network load information. The general concept 
of pushing and polling information is well known in the art as 
shown in Figure 3, following item 302 to decide whether push or 
pull. It would have been obvious to one in skilled in the art at 
the time of the invention to modify Adelman et al and Fleming, 
to push or pull network information in order to implement 
authentication process as taught in Rashid et al (see Page 3, 
Para 0036-0042 for push based process and Para 0043-0045 for 
pull based process 

Claim 16 is rejected under 35 U.S.C. 103(a) as being 
unpatentable over Adelman et al and Fleming in view of rfc2543. 

For claim 16 Adelman et al and Fleming teach all claim 
limitations except SIP message is being used as keepalive 
message. The general concept of using an SIP message as 
keepalive message is well known in the art as illustrated 
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Internet draft session timer (page 3, second Para, "... this 
extension defines a keepalive mechanism for SIP sessions."). It 
would have been obvious to one skilled in the art at the time of 
the invention to modify Adelman et al and Fleming to use SIP 
message as keepalive message in order to create sessions as 
taught in RFC 2543 (RFC 2543, page 1, Abstract, first line, "The 
Session Initiation Protocol (SIP) is an application-layer 
control (signaling) protocol for creating, modifying and 
terminating sessions with one or more participants", which 
teaches SIP can be used to create sessions) . 

Claim 18 is rejected under 35 U.S.C. 103(a) as being 
unpatentable over Adelman et al and Fleming in view of Aharoni 
et al (US 6014694) . 

For claim 18, Adelman et al and Fleming teach all the claim 
limitations (as discussed supra) except changing keepalive 
period based on threshold change in network load. The general 
concept of changing timer value is well known in the art as 
illustrated in Aharoni et al (FIG. Item 116, "Bytes Online 
[network load] Recommended Bytes Online? [threshold]", yes no 
change, No, set TIMEOUT=1000 (setting a timeout period, i.e. 
setting keepalive time period to 1000, and waiting for 
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acknowledgment from item 120) . It would have been obvious to one 
in skilled in the art at the time of invention to modify Adelman 
et al and Fleming to change the keepalive period based on 
threshold change in network load in order to measure network 
bandwidth as taught by Aharoni et al (FIG. 11, starting step, 
"BANDWIDTH MEASUREMENT SCAN PHASE") . 

9. Claim 21 is rejected under 35 U.S.C. 103(a) as being 
unpatentable over Adelman et al and Fleming view of Harsch and 
Rashid et al . 

For claim 21, Adelman et al, Fleming and Harsch (as discussed 
supra in claim 20) teach all claim limitations, except polling 
the network load information from the controller. The general 
concept of polling information is in well known in the art as 
illustrated in Rashid: Figure 3, following item 302 to decide 
whether poll or push. It would have been obvious to one skilled 
in the art at the time of the invention to modify Adelman et al 
, Fleming and Harsch to poll the network load information in 
order to implement authentication process as taught in Rashid et 
al (Rashid: Page 3, Para 0043- 0045 for poll based process) . 
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10. Claim 23 is rejected under 35 U.S.C. 103(a) as being 
unpatentable over Adelman et al and Fleming in view of Harsch 
and Aharoni et al (US 6014694) . 

For claim 23, Adelman et al, Fleming and Harsch teach all the 
claim limitations except keeping track of the network bandwidth. 
The general concept of keeping track of network bandwidth is 
well known in the art as illustrated by Aharoni et al (Aharoni: 
FIG. 12, sender keeping (calculating) track of bandwidth as 
shown in the top start item) . It would have been obvious to one 
in skilled in the art at the time of invention to modify Adelman 
et al, Fleming and Harsch to keep track bandwidth use in order 
to determine new time to send as taught in Aharoni et al . (see, 
Aharoni: FIG. 12/2, item 160). 

Conclusion 

The prior art made of record and not relied upon is 
considered pertinent to applicant's disclosure. 

Any inguiry concerning this communication or earlier 
communications from the examiner should be directed to Yasin 
Bargadle whose telephone number is 571-272-3947. The examiner 
can normally be reached on 9:00 AM to 5:30 PM. 
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If attempts to reach the examiner by telephone are 
unsuccessful, the examiner's supervisor, Glenn Burgess can be 
reached on 571-272-3949. The fax phone numbers for the 
organization where this application or proceeding is assigned 
are 703-872-9306 for regular communications and 703-746-7238 for 
After Final communications. 

Any inquiry of a general nature or relating to the status 
of this application or proceeding should be directed to the 
receptionist whose telephone number is 703-305-3900. 

Information regarding the status of an application may be 
obtained form the Patent Application Information Retrieval 
(PAIR) system. Status information for published applications may 
be obtained from either private PAIR or public PAIR system. 
Status information for unpublished applications is available 
through private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have 
questions on access to the Private PAIR system, contact the 
Electronic Business Center (EBC) at 866-217-9197 (toll-free) . 



/Yasin M Barqadle/ 

Primary Examiner, Art Unit 2153 



